Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@jestHelpers/setup.js`:
- Line 7: Replace the minimal stubbed Response class (global.Response = class
Response {}) with a full fetch/Response polyfill; either import and invoke the
existing whatwg-fetch or undici fetch polyfill in jestHelpers/setup.js so
global.Response (and associated properties/methods like ok, status, json, text,
body) are provided instead of the empty class, ensuring any code that uses
Response (e.g., assistant-stream) gets the expected behavior.

In `@manifest.webapp`:
- Around line 217-226: Replace the broad verbs ["ALL"] on the permissions
objects chatConversations and assistants with least-privilege verb lists that
match actual usage (e.g., only read/create/update verbs such as GET, POST,
PUT/PATCH) so DELETE is not implicitly granted; update the "verbs" arrays on the
chatConversations and assistants entries to the minimal set required by the
feature, and only retain "DELETE" if the code explicitly requires conversation
deletion.

In `@src/lib/doctypes.js`:
- Around line 38-47: Replace the hardcoded doctype string in the
conversations.relationships.assistant block with the DOCTYPE_AI_CHAT_ASSISTANTS
constant: locate the conversations object (symbol DOCTYPE_AI_CHAT_CONVERSATIONS)
and update the assistant.relationships.type value that currently reads
'io.cozy.ai.chat.assistants' to reference DOCTYPE_AI_CHAT_ASSISTANTS so the
module uses the defined constant rather than a literal string.
- Around line 14-15: Add a schema entry for the assistants doctype so
cozy-client can normalize/cache assistant docs: create a schema object keyed by
DOCTYPE_AI_CHAT_ASSISTANTS (the same constant exported alongside
DOCTYPE_AI_CHAT_CONVERSATIONS) mirroring the pattern used for the conversations
schema (include id, relationships, and any necessary attributes) so
RealTimeQueries/AssistantLayout.jsx subscriptions and the conversations schema
relationship target are properly recognized and normalized by cozy-client.

In `@src/modules/views/Assistant/AssistantLayout.jsx`:
- Around line 16-36: AssistantLayout is not reading the route parameter
conversationId defined on the route; update AssistantLayout to import and call
useParams() to extract conversationId and pass it into <AssistantView
conversationId={conversationId} /> (or, if the route param is unnecessary,
remove conversationId from the route instead); specifically modify the
AssistantLayout function to const { conversationId } = useParams() and forward
that value to the AssistantView component (or coordinate route change if you
choose to remove the param).

---

Nitpick comments:
In `@src/modules/navigation/AppRoute.jsx`:
- Around line 58-60: The filter on BarRoutes using r.props?.path !==
'assistant/:conversationId' is brittle; extract the path string into a shared
constant (e.g., ASSISTANT_CONVERSATION_PATH) and use that constant when
filtering and elsewhere (referenced in filteredBarRoutes and any other uses
around line ~84) and defensively handle missing path values by coercing to a
string or using optional chaining (e.g., const path = r.props?.path ?? '')
before comparison so the filter won't silently fail if props or path are absent.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/modules/navigation/AppRoute.jsx`:
- Around line 58-60: Add a brief inline comment above the filteredBarRoutes
declaration explaining that BarRoutes may include an 'assistant/:conversationId'
route from cozy-bar and we filter it out to avoid duplicate route definitions
because the app adds the assistant route explicitly elsewhere; reference the
filteredBarRoutes constant and the path 'assistant/:conversationId' so future
maintainers understand the intent.